Conventionally, a navigation terminal detects its current location, that is, an origin of a trip through a Global Positioning System (GPS) connection, receives information about a destination of the trip from a user, and internally calculates a route based on the origin and the destination. Along with the recent proliferation and increased performance of smartphones, services have become popular, in which a traffic and route information providing server provides route information, real-time traffic information related to routes, and other various information to Personal Navigation Devices (PNDs) over a mobile communication network.
Particularly in the situation where various navigation services are available, the Open Mobile Alliance (OMA) standardization organization is working on standardization of Dynamic Navigation Enabler (DynNav) that provides real-time traffic information by Peer to Peer (P2P) communication through an Internet Protocol (IP)-based network of a mobile communication network or a wireless network, rather than Traffic Protocol Expert Group (TPEG) information is transmitted over a Digital Multimedia Broadcasting (DMB) network that provides information in a broadcast signal. The standard considers a navigation terminal and a service type largely in two ways for a smartphone.
First, a traffic and route information providing server performs complex route computation, instead of a navigation application loaded in a smartphone, and indicates a calculated route to the smartphone. Second, owing to the improved performance of a smartphone, an application loaded in the smartphone performs or a navigation terminal equipped with a mobile communication modem performs route computation. In this case, the traffic and route information providing server does not provide route information. Rather, once the terminal registers a calculated route to the server, the terminal can receive from the server only real-time traffic information related to the registered route in a customized manner by IP-based P2P communication, not in a conventional broadcast signal.
FIG. 1 illustrates Navigation Device (ND) types. NDs may be classified into a type 110 that additionally provides TPEG-based traffic information transmitted through a broadcasting network such as a DMB network, a type 120 that additionally provides traffic information in an IP-based manner, for example, over a mobile communication network or a Wireless Fidelity (Wi-Fi) network, and a standalone type 130 that tracks the location of a vehicle through a GPS connection without connecting to other communication media, generates route information, and provides the route information.
DynNav under standardization in the OMA LOC WG belongs to the type 120 that provides IP-based traffic information, specifically by P2P communication. The following two types of NDs are defined in DynNav.
1. Smart ND: a device that can calculate a route on its own and thus requests only real-time traffic information to a DynNav server without receiving route information from the DynNav server.
2. Lightweight ND: a device that cannot calculate a route on its own and thus requests all real-time traffic information including route information to a DynNav server.
Since traffic information is requested and provided in a RESTful-based manner in a conventional DynNav system, the following route information formats are used and each information format can be defined by XML Schema Definition (XSD).
1) Trip Structure: a terminal initially acquires basic information such as an origin and a destination from a user, for route setting, and provides the acquired information to a server. The trip structure includes subsets corresponding to a plurality of route structures.
TABLE 1ElementTypeOptionalDescriptionoriginWGS84Location_PointYesLocation information about an originrepresented by WGS84 (Location_Pointstructure is defined in tpeg-locML [TTI LOC].At least one element originWGS84 ororiginAddress MUST be specified.)originAddressCivic LocationYesLocation information about the originFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element originWGS84 ororiginAddress MUST be specified.)destinationWGS84Location_PointYesLocation information about a destinationrepresented by WGS84 (Location Pointstructure is defined in tpeg-locML [TTI LOC].At least one element destinationWGS84 ordestinationAddress MUST be specified.)destinationAddressCivic AddressYesLocation information about the destinationFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element destinationWGS84 ordestinationAddress MUST be specified.)waypointsLocation_PointYesLocation information about a way point[0 . . . unbounded](represented by WGS84)(Location_Pointstructure is defined in tpeg-locML [TTILOC].)startingTimexsd:dateTimeYesStarting time of navigation service (if a servicestarting time is specified, the trip is a plannedtrip. If a service starting time is not specified,a current time is the service starting time).(starting time of the planned trip. If notpresent, current time is assumed.)tollRoadxsd:booleanYesIt indicates whether passing through a toll roadis allowed. (If true or not present, a toll road isallowed.)vehicleTypeVehicle_InfoYesInformation about a used vehicle(Vehicle_Info structure is defined in tpeg-rtmML [TTI RTM].)calculateRoutexsd:booleanYesIt indicates whether the server provides acalculated route. (If false or not present, theserver should not propose routes.)linkcommon:LinkYesLin information about routes defined in the[0 . . . unbounded]trip. (Links to routes related to the trip.Attribute “rel” must be set to “Route”.)resourceURLxsd:anyURIYesSelf-referring URL information (Self-referringURL. SHALL NOT be included in POSTrequests, MUST be included in responses toany HTTP method that returns an entity body,and in PUT requests.)
2) Route Structure: a route structure is expressed as a plurality of segments as a way to represent total routes calculated using the trip structure.
TABLE 2ElementTypeOptionalDescriptiontravellingTimexsd:floatYesTotal travelling time (in minutes) for the routedistancexsd:floatYesTotal distance (in Km) of the routeoriginLocation_PointNoOrigin of the route (represented by WGS84)(Location_Point structure is defined in tpeg-locML [TTI LOC].)segmentSegmentNoSequence of road segments that form the route[1 . . . unbounded]trafficEventsCategorizedEventYesInformation about links accessing trafficListReferenceinformation resources (List of traffic events as[0 . . . unbounded]defined in tpeg-rtmML [TTI RTM], groupedinto categories.)linkcommon:LinkYesReference to the route for which it is proposedas alternative. Attribute “rel” must be set to“Route”.resourceURLxsd:anyURIYesSelf-referring URL. SHALL NOT be includedin POST requests, MUST be included inresponses to any HTTP method that returns anentity body, and in PUT requests.)
3) Segment Structure: it is a structure that represents each segment. The segment structure may define a real-time traffic state corresponding to the segment as well as the length of the segment, in TPEG.
TABLE 3ElementTypeOptionalDescriptionendPointLocation_PointNoLocation information about the end point of eachsegment (represented by WGS84)(Location_Pointstructure as defined in tpeg-locML [TTI LOC]. Thestarting point of the segment should be assumedequal to the ending point of the previous segment (orthe trip origin for the first segment))midwayPointLocation_PointYesLocation_Point structure as defined in tpeg-locML[0 . . . unbounded][TTI LOC].linkNamexsd:stringYesName of the road that the segment belongs todistancexsd:floatYesLength of the segment in kmtravellingTimexsd:floatYesEstimated average time to cover the segmentexpressed in minutes. It includes regular travellingtime and delay.delayxsd:floatYesEstimated delay along the segment expressed inminutes.speedxsd:floatYesEstimated average speed along the segmentexpressed in m/s.performancexsd:stringYesInformation about traffic state (levels may be definedto indicate delay, congestion, and severe congestion).(Description of traffic conditions along the segment.This field should be encoded according to tpegrtmML definition [TTI RTM].)
FIG. 2 is a diagram illustrating a signal flow for an operation of a lightweight ND in a conventional DynNav system. Because the lightweight ND does not support route calculation in view of its capability, the lightweight ND should request route information to a server and receive the route information from the server. The lightweight ND has the following main functionality.
1. The lightweight ND transmits trip information to the server, for use in route calculation at the server.
2. The lightweight ND receives information about a set of routes (including a recommended route) calculated by the server from the server.
3. The lightweight ND subscribes to a notification service to receive real-time traffic information from the server.
The signal flow illustrated in FIG. 2 contains the followings, on the whole.
1. The user defines journey parameters, and the application sends the parameters to the server; the server calculates a set of proposed routes based on the received parameters with related traffic information. The server replies with the location of the created “trip” resource to the application.
a) The server may reply with a representation of created “trip” resource, which contains resources identifiers of the proposed routes. In this case, message 2 is no longer required.
2. The application uses the trip resource to access trip's information which contains resources identifiers of the proposed routes.
3. The application uses the Route Identifier to access information describing each single proposed route with links to traffic events and performance parameters.
4. The application accesses then to traffic events related to the route, using links to traffic event resources provided in the route structure.
5. The user selects a route among the set of routes for which he is interested in receiving updated performance parameters and traffic events, and alternative routes when available.
6. The application requests to the server to create a subscription to notification service for the trip and route(s). The application is notified by the server of the following events:                New performance parameters and changes in traffic events, notification resource will include links to already existing routes resources.        Proposal of alternative routes due to traffic problems along the proposed routes; the notification resource will include the link to trip resource.        
7. Traffic events and/or changes of performance parameters occur on the subscribed route(s): a notification resource is created.
8. The server delivers the notification resources to the application with links to modified resources, including the trip and the route with the updated traffic information (traffic events and performance parameters).
9. The application accesses the updated resources. The resources should be reflected in appropriate way.
10. The application request to modify the subscription setting adding notification for the new route. Just in case, the updated resource is an alternative route in step 9.
FIG. 3 is a diagram illustrating a signal flow for an operation of a smart ND in the conventional DynNav system. Because the smart ND supports route calculation in view of its capability, the smart ND calculates a route on its own based on trip information defined by a user and transmits information about the calculated route to a server. The smart ND has the following main functionality.
1. The smart ND calculates a route based on trip information.
2. The smart ND transmits information about the calculated route to the server and the server notifies the smart ND of a real-time traffic state.
3. The smart ND subscribes to a notification service based on the transmitted route information in order to receive real-time traffic information from the server.
The signal flow illustrated in FIG. 3 contains the followings on the whole.
1. The user defines journey parameters and the application sends parameters to the server. The server replies with the location of the created “trip” resources to the application.
a) The server may replay with a representation of created “trip” resource. In this use case behaviors are equivalent.
2. The application uploads the calculated route under the resource/{tripId}/routes. The server replies with a representation of the “route” resource, which contains performance parameters and links to traffic events.
a) The server may reply with the traffic information (performance parameters and traffic events). In this case an additional get operation is needed to retrieve content of resource.
3. The application subscribes to notification service for the trip and route.
4. Traffic events and/or changes of performance parameters occur on the subscribed route(s); a notification resource is created.
5. The server delivers the notification resource to the application with links to the modified resources, including the trip and the route with updated performance parameters and traffic information.
6. The application accesses to the updated resources and read the resources.
7. The application decides to calculate a new route with the received resources.
8. The application uploads the new calculated route under the resource/{tripId}/routes. The server replies with a representation of the “route” resources, which contains route performances and links to vents. This step may be repeated many times until a route that satisfies performance constrains is found.
9. The application requests to modify the subscription setting adding notification for the newly subscribed route.
The lightweight ND and the smart ND in the conventional DynNav system as described with reference to FIGS. 2 and 3 suffer from some problems. These problems will be described below. Since the problems vary with the ND types (lightweight or smart), the problems will be described in relation to the individual ND types.
A) When the Smart ND Calculates an Initial Route, the Smart ND Cannot Apply Real-Time Traffic Information.
A problem with the smart ND in the conventional technology is that the smart ND cannot use real-time information appropriately in route calculation. The route calculated by the smart ND in step 2 of FIG. 3 does not reflect real-time traffic information at all. Since the smart ND cannot use real-time traffic information as route information, a high-quality route guidance service cannot be provided to the user. Moreover, an operation for tracking the route that does not reflect real-time traffic information by the server, subsequently to step 2 in which the smart ND transmits information about the calculated route to the server, may be unnecessary.
Another problem that may be encountered with the smart ND is unnecessary consumption of network resources. As in step 8 of FIG. 3, the ND transmits information about its calculated route a plurality of times in order to search for an optimal route. The above-described operation for detecting an optimal route may be performed in various manners depending on methods and designs. When speaking of probability, an optimal route may be detected by transmitting route information one or more times. Continuing a transmission operation with uncertain probability may lead to unnecessary consumption of network resources. From the perspective of the user using the ND, this means excessive cost and a lengthened time for detection of an optimal route, which may disturb safe traveling of the user.
In general, information that the ND receives from the user is the location of a user-intended destination. Without real-time traffic information, the terminal generally calculates a route in a shortest road-first or express way-first manner. As illustrated in FIG. 4, since the smart ND does not reflect real-time traffic information in calculating an initial route, the smart ND calculates a shortest route running through S-4-A-b-D. However, an actual optimal route is S-1-A-a-D in consideration of congestion roads marked in FIG. 4 (c1 denotes a congestion-free road, c2 denotes a normal-congestion road, and c3 denotes a severe-congestion road). If the terminal travels in the corresponding route, the user experiences congestion even from the start of the trip and then will pass through a road b under construction. This implies that in the case of severe traffic congestion within a reference radius of an origin as illustrated in FIG. 4, there is a need for the server to provide corresponding traffic information.
B) Problem Encountered when the Current Location of a Terminal is Not Known.
This problem is common to both the lightweight ND and the smart ND. For simplicity of description, the smart ND will be taken as an example. After calculating a route, the smart ND transmits information about the calculated route to the server and the server continuously estimates the state of the route to provide a notification service for the route.
However, the estimated overall route uploaded by the ND is effective only at the moment of the upload. Once a vehicle carrying the smart ND travels in the route for a certain distance, estimation of the state of the route for the distance or delivery of information about the estimated route state to the smart ND is meaningless. That is, in the case where the server does not know the current location of the serviced smart ND, the server transmits unnecessary information to the smart ND. This means transmission of unnecessary information and the resulting power consumption on the part of the network and unnecessary resource consumption for the management of information transmission on the part of the server.
FIG. 5 illustrates a problem encountered when a server does not know the current location of an ND. As illustrated in FIG. 5, after a predetermined time elapses, segments 100b and 101b need route estimation. If total routes are denoted by 100a and 101a, the total routes 100a and 101a are different from the segments 100b and 101b with the passage of time. These differences do not need management. In this context, the present invention is intended to solve the problem that occurs due to the absence of knowledge of the current location of a terminal.
C) Problem During Transmission of Summarized Route Information.
This problem occurs to the lightweight ND. When the server calculates routes based on real-time traffic information and transmits information about the calculated routes to the lightweight ND, the following operation is performed.
1. The ND transmits origin information and destination information to the server.
2. The server generates a plurality of routes based on the received origin and destination information.
3. The ND or its user subscribes to a traffic information notification service to select a route, transmit information about the selected route, and receive the traffic information notification service.
4. The ND performs a navigation service along the selected route.
During the above procedure, the server typically generates a plurality of routes and transmits information about the plurality of routes to the ND to increase the quality of a service experienced by the user and widen a selection range for the user. Then the ND or its user may select one of the plurality of routes. The problem herein is that the user should receive all of actually unnecessary route information and after selecting one of the routes, the user deletes the remaining route information. As a consequence, network resources may be wasted.
To overcome the problem encountered with steps 1 to 4 described above, it has been proposed that only a summary of information about calculated routes is initially transmitted to an ND. In order to prevent network resource waste, the server selectively transmits a part of the information about the calculated routes (e.g., important segment information, traveling times, toll, etc.) to the ND. Then the ND or its user selects one of the calculated routes based on the received information (i.e. a summary) and/or the user's preferences and notifies the server of the selected route. Thus the server transmits only full route information about the selected route from among the plurality of routes to the ND in response to the request.
Nonetheless, the conventional technology still suffers from a problem. This problem occurs when the distance between an origin and a destination is short. If the distance between an origin and a destination is short, the size of transmitted segment information is small. Thus, a summarizing operation of the server to generate a summary of route information and interaction between the server and an ND may degrade the performance of a navigation system. In other words, there is no need for transmitting summarized route information in this case. Rather, it may be preferred to transmit full route information.